The reply from Engineer got me on the track for macOS. It seems even so the input device is correctly selected in system preferences and is returned as current input device, the AVAudioEngine inputNode uses a different device id. Now when manually setting the inputNode AUAudioUnit id to the wanted input device ( code taken from a reply here: https://forums.developer.apple.com/forums/thread/71008 ), i can tap the USB microphone and analyse its input data. So while the above reply does not solve the question, it gave the right hint and put me on track quickly.

Updated macOS to 14.1 and Xcode to 15.0.1. Built my app and opened one of the existing documents that lead to above crash. Adding and deleting item now worked. Created a new document. All worked well after reopening. Seems the update fixed it for me. Can anyone confirm? thx volker

After updating to Ventura 13.3 the error is gone. So as expected, internal bug. Happy.

Thx! I get the string entered in a search field (created using .searchable() ) Upon submission of the search (by pressing enter) I call a function: private func searchPredicate(query: String) { if self.searchControl.originalPredicate == nil { self.searchControl.originalPredicate = items.nsPredicate if items.nsPredicate == nil { self.searchControl.originalPredicate = NSPredicate(format: "TRUEPREDICATE") } } var predicate: NSPredicate? if self.searchScope == .title { predicate = NSPredicate(format: "%K CONTAINS[cd] %@", #keyPath(Article.title), self.searchText) } else if searchScope == .authors { predicate = NSPredicate(format: "%K CONTAINS[cd] %@", #keyPath(Article.authorsForDisplay), self.searchText) } DispatchQueue.main.async { self.items.nsPredicate = NSCompoundPredicate(andPredicateWithSubpredicates: [self.searchControl.originalPredicate ?? NSPredicate(format: "TRUEPREDICATE"), predicate!]) } } When calling this line: self.items.nsPredicate = NSCompoundPredicate(andPredicateWithSubpredicates: [self.searchControl.originalPredicate ?? NSPredicate(format: "TRUEPREDICATE"), predicate!]) The crash will occur - or as often - not. This works for most search string. Only some strings repeatedly cause the mentions crash. for example if I enter wasser it crashes. If I enter bat or evident or turbine or curtail or... it doesn't. All valid and normal strings. Searches with zero results work as well, so entering xcojfoesjif will not give a crash. So far I can reproduce the crash using washer or human - I have not tried more words yet. When I look at the call stack, it happens within private functions handling the Table display. There is no refresh code for the table since the the following fetch request is used - and it does automatically pre-render the view (as a @State would do): @FetchRequest( entity: Article.entity(), sortDescriptors: [NSSortDescriptor(keyPath: \Article.year, ascending: false)], predicate: NSPredicate(format: "TRUEPREDICATE"), animation: .default) private var items: FetchedResults<Article> I do not have a single line where I rely on an index for the data array. All done magically by SwiftUI. Otherwise it would be easy to solve ;) The code is on Github: https://github.com/vrunkel/Peru I can also supply my test data which needs to be imported from xml first. To me it looks like a bug in SwiftUI's table implementation. Since the call stack contains _delegate_isGroupRow: before the crash, I wonder if for some reason the table wants to create sections? I don' have sections as seen in the code sample above regarding table display. Hope that clarifies!